home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Oct 89 / Z0065-Re[2] Changing MacA-Oct89 < prev    next >
Encoding:
Text File  |  1989-10-13  |  2.4 KB  |  53 lines  |  [TEXT/GEOL]
  1. Item    1319256                         12-Oct-89        17:56
  2.  
  3. From:   ROSENSTEIN1                     Rosenstein, Larry
  4.  
  5. To:     D4071                           Aapps, Russ Wetmore,PRT
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    Re: Re: Changing MacApp Source
  10.  
  11. Russ,
  12.  
  13. Your view holder object from ViewEdit is a kind of delegation.  You create a
  14. new class that delegates some of its responsibility to an existing TView
  15. object.  Since Object Pascal doesn't directly support this, you need to write a
  16. bunch of methods to explicitly do the delegation.  Also, the resulting class
  17. won't be type-compatible with TView (unless, of course it descends from TView
  18. as well).
  19.  
  20. Stroustrup proposed adding delegation to C++.  You would declare a class as
  21. descended from a pointer to an object (sort of).  The name space of methods
  22. understood by the new class would include all the methods defined by the static
  23. type of the pointer.  (It doesn't look as if he will actually add this to C++.)
  24.  
  25. As for the original question of changing the MacApp source, one possibility is
  26. to simply linking a separatly compiled module into the MacApp library to
  27. replace a given routine.  If you lib together a new object module along with
  28. MacApp.lib (in that order) then the object file can replace any module in the
  29. library.
  30.  
  31. The tricky part is generating the appropriate object module.  This requires a
  32. bit of knowledge about how Object Pascal names things (which is easy to figure
  33. out.)  Then you need to generate a module of the appropriate name.  One way to
  34. do this is as follows.
  35.  
  36. Suppose you want to replace MacApp's version of TView.Draw.  You subclass TView
  37. and override Draw with your own implementation.  Compile the unit.  Then use
  38. the lib tool to rename your overridden module to use TView as the class name.
  39. The you can lib this with MacApp.lib and replace the old version of TView.Draw.
  40. It might also be possible to specify the new object module in the make file,
  41. and have it linked in each time.  (That way MacApp.lib does not have to change,
  42. and you can automatically rebuild the file when needed.)
  43.  
  44. Since you never changed the sources, there is no problem when a new version of
  45. MacApp comes out, provided your change is still applicable.  If you don't
  46. change MacApp.lib, then you don't have to do the lib step either.
  47.  
  48. This won't help if the original MacApp routine accesses some private data, but
  49. I think in MacApp 2.0 this has been improved.
  50.  
  51. Larry Rosenstein
  52.  
  53.